1. Technical Field
Embodiments described in this disclosure generally relate to development tools, and more particularly to using auto code generation to generate packet header generation libraries for switch diagnostics.
2. Description of the Related Art
Switching and routing devices often provide the ability to run a variety of self-diagnostic and validation tests. For example, during a power on self-test (POST), a switch may generate and send a variety of packets to ports on a device to ensure such ports are functioning properly. Similarly, switching and routing devices may allow users to compose relatively simple testing scripts to test and diagnose the functioning of these devices. Such testing and validation processes frequently require the switching or routing device to generate a broad variety of network packet/frame headers. Accordingly, the firmware running on these devices typically includes modules to internally generate the packet headers needed by these testing/validation routines. Behind these modules, developers have to write code to generate headers as needed by the testing/validation routines. As new protocols (both proprietary and standardized) are developed, new header libraries have to be created and added to the firmware on the switch.
While some packet generation tools are available, they typically have a number of dependencies on other packages or libraries, as well as dependencies on specific development environments (e.g., a particular compiler version or system architecture). Thus, using these tools to generate packets in switch firmware requires developers to port any necessary source code and header files into a format appropriate for the firmware. However, the amount of space allocated in the firmware for diagnostic routines can be relatively limited. This frequently precludes developers from using full-fledged packet-generation libraries due to firmware size limitations, as these libraries do not allow them to describe packet headers using the library without fully integrating the library, which may include a variety of unneeded elements (e.g., function to transmit/inspect packets). Thus, even where developers are willing to port the necessary code or header files, doing so may result in a packet generation facility that exceeds the space limitations of switch firmware. Further, the interfaces for such library may be available only in a procedural language (e.g., the C programming language), making it difficult to invoke the functions provided by these interfaces from commonly used scripting languages, (e.g., Perl scripts). Further still, currently available packet generation tools may simply be incapable of generating certain packet header types, e.g., packet header types defined by standards developed following the version of the library or proprietary packet header definitions used by proprietary protocols.
Accordingly, porting the available packet-generation libraries just to obtain the packet header generation needed by the diagnostic/testing portions of firmware is both time consuming and can result in a bloated firmware footprint. Because of this, in many cases, it becomes easier for developers to write packet header generation libraries on a “one-off” basis.